The WildApp struct ...
That doc will show you what is the WildApp, your door to the Wild world.
You should also see Wild.h (or .i, better documented).
The WildApp struct is returned by AddWildApp func, the first thing
you have to do after you opened Wild in your program to do anything. This
contains a lot of info that identify your app and more. Let's see the important
fields.
- wap_Node : simply the node that links
all the apps to the WildBase.
- wap_FastPool : an Exec's Pool to allocate
everything is related to the app. So, objects and structs are allocated
from this. You can modify via tags the size of puddles and thresh when
you start-up a new app. That's allocated with MEMF_ANY flag, so if FastMem
is present, it's used, otherwise, ChipMem is used.
- wap_ChipPool: identical, but this pool
is surely in ChipMem.
- wap_Engine : this contanis the pointers
to all the module sublibraries you have in your Engine: the parts of an
Engine are: Display, TDCore, Light, Draw, FX, Sound*, Music*, Broker,Loader
(* those were planned at start, but not implemented now. maybe in the future...
thinked features were 3D sound, and music changing depending from 3D position,
but... to re-think.).
- wap_EngineData : this contains some
PRIVATE module's pointer: the modules MUST use this pointer to have a struct
with the data referring the specific App. For example, if a Display module
needs to store somewhere 3 screens to do triple buffering, MUST allocate
his structure from the WildApp's FastPool, and store the pointer here.
That's because a module can be shared by more then one App, so can't store
in his own base or variables. The coder of a WildApp should NEVER touch
these, because don't know what kind of struct is here, and also are not
his businness.
- wap_Types (A-H) : this
is a very important field, because it's the method used by Wld to make-up
a compatible Engine. For example, you can't use a PLANAR Display
module if the Draw module asks for a Chunky. So, I introduced Types.
That is not only a WildApp field, but also every module has it. These
are 8 bytes wich define the type of many things; for example, the type
of Display: PLANAR or CHUNKY8 or CHUNKY15 or CHUNKY24 (or anyother in the
future).
In Wild.h you can see the types available now. For example, the Type
B is the one defining the Display. So, if you specify a specific type of
display you want, the Display module, and so the Draw module and the PostFX
module must have the same type, or they will write wrong things. In the
future will be checked by Wild, and repaired selecting a new module, but
now no check. If you specify a type as 0 means FULLCOMPATIBLE. So, you
don't care about what display and let the Draw and PostFX modules ask whatever
they want. This forbids you to write in the Display buffer, obviously,
because you don't know what kind of buffer is used. If you want to, you
must write many drawing routines for the different types you have, and
then select by checking the Display's TypeB.
Example: you want to write the FPS or the SCORE of your game, but you
set TypeB to FULLCOMPATIBLE. You have to write a routine to write fps in
PLANAR, in CHUNKY8 and in CHUNKY15 and anyother existing Display. Then,
check the Display's TypeB and select. If the type is unknow, DON'T try
to access the Display: better having a working game without SCORE than
a bad crash.
- wap_FrameBuffer: this contains a struct
allocated and updated by the Display module, wich contains all the info
to let the App and the other Modules access the Display, so the Screen's
address, the Chunky's address. It's not a fixed structure, but is decided
by Types.
- wap_Scene : this contains the pointer
to the Scene displayed.
- wap_Flags : internal of shared flags.
- wap_Tags : IMPORTANT field:
is a pointer to a taglist where ALL the WILD'S TAGS (but NOT the USER ONES)
are stored and kept, to be read by any module or even by the app,
if forgets something.